feat: (anti)feature - remove poetry.lock from solution template #506
Conversation
|
I forgot to include them, but here is a before/after of the resulting package versions (from The diff shows the extent of how outdated the current lock file is: |
|
@vgelbgras The E2E tests are failing. I dug into the error a bit, but can't find any issues. I can reproduce the error using the validation repo - the only discrepancy I noticed is that the poetry.lock file generated by the E2E tests lists |
|
Or it may be a true test incompatibility with the upgrade from glow-engine 1.11.2 to 1.12.0 - over 250+ files changed, so it is tough for me to see if there is a breaking change lurking in the changelog somewhere: https://github.com/ansys-internal/glow-engine/compare/v1.11.2...v1.12.0 |
@nick-marnik |
|
@vgelbgras I am not familiar with those tests - instead of removing them, is there someone involved in writing them who could over some insight into how they should be refactored? |
|
Hi @nick-marnik |
|
Hi @nick-marnik, the entry point for this tests is the solution-templates-end-to-end-testing repository. I have not been tasked with maintaining this repository since SAF teams reorganized, but feel free to ask me if there is anything you need help with. I have given write access to the repository to the solutions developers team. The only thing that would need to be directly modified on the basic-solution-template-validator are the workflow files which are committed to the main branch and are retrieved from solution-templates-end-to-end-testing while creating the solution to be pushed (This looks like a clunky way to work, I do not recall if there was a constraint in the way actions work that pushed me to implement it like that. May have been a rookie thing). |
I think I was the guilty person who originally added the
poetry.lockfile to the solution template. I stand by this decision, but I think that over time circumstances have changed a bit and I have noted a few negatives to this approach:pyproject.tomlis annoying because you need to instantiate a copy of the template and update thepoetry.lockfile manuallypyproject.tomlwith version range specifiers do not ever get updatedThis PR removes the
poetry.lockfile from the template. However, due to the way thesetup_environment.pyscript works, a newpoetry.lockfile will be generated upon first use of the template. This approach fixes the above negatives:pyproject.tomlwithout any other changespoetry.lockfile updatedThere is one main risk/drawback to the new approach: the template itself is no longer deterministic (stable). The solution template is now dependent on when it is instantiated. I don't think this is inherently bad, but is something we will need to keep in mind. Specifically, we will need to write the version ranges for our packages very carefully to ensure that the package version upgrades we consume automatically are compatible with the template contents.
If we ever find a package upgrade that breaks the solution template, I don't think the remedy is to add the
poetry.lockfile back. Instead, we should update the version range specification for said package to prevent the issue.I also think that the E2E tests created by the framework team are now even more important than before. If there are package incompatibilities, they should be surfaced by the E2E solution tests. We should confirm that those tests are all functional, running on a cron schedule, and the results are being monitored by someone on the framework team.